Gemini Proxy
implementing client certificate support
* 📧 Messages: 17
* 🗣️ Authors: 6
* 📅 First Message: 2020-06-07 18:54
* 📅 Last Message: 2020-06-10 21:16
1. mbays (a) sdf.org (mbays (a) sdf.org)
* 📅 Sent: 2020-06-07 18:54
* 📧 Message 1 of 17
[This post is also a glog entry at
gemini://gemini.thegonz.net/glog/200607-clientCertificatePostMortem.gmi]
I just finished adding client certificate support to my line-based
textual gemini client diohsc. This involved making some non-trivial
choices, and I didn't copy av98 in all cases, so I hope discussing the
decisions I made and the reasoning behind them could be of use to other
client developers and in refining the spec.
>> User interface
* The technical terminology "client certificate", which describes an
implementation detail rather than the underlying concept, is mostly
hidden from the user. Instead, the client talks about "identities". An
identity is just a client certificate along with an optional name.
* In diohsc, there are two kinds of identity -- temporary anonymous
identities and long-term named identities. The latter are saved to disc,
the former are held only in memory.
* There is no way to name and save an anonymous identity. Allowing it
would complicate the UI and the conceptual distinction between the two
kinds of identity.
>>> Creating identities
* When 61 is received, the user is asked if they want to create an
anonymous identity.
* On any other 6* error code, the user may select an existing named
identity or create a new named or anonymous identity, and then retry the
request.
* When creating a named identity, the user is prompted to set a Common
Name (which can be empty). This is the only choice required of the user.
It would make for a neater UI to automatically set the Common Name to be
the name of the identity, and in some ways it would make sense. But the
user may well want to use the same Common Name (e.g. "anon" or "") on
multiple servers without a common identity.
>>> Using identities
* An identity can be set to be used on a given server at and below
a given URI path. So you can have one identity in use for
gemini://foo.bar/~quux/..., and another for gemini://foo.bar/~xuuq/...
* Whenever an URI is shown to the user, it is annotated with the
identity, if any, which would be used if it were requested; e.g.
"gemini://foo.bar/~xuuq/hello.gmi[clarkKent]". This includes relative
URIs in links. So the user knows when they're going to use what
identity.
* Colouring is used to visually separate the annotation from the URI
(but '[' and ']' are reserved characters in URIs, so this isn't actually
necessary).
* Anonymous identities are denoted as "[]".
* If the user requests an URI which would use an identity which hasn't
been used in 30m, they are asked to confirm whether they want to still
use it. If they don't want to, the identity is disabled for this path.
>>> Controlling identities
* There is a single new command added to deal with identities: "identify
[URI]". If URI is missing, it defaults to the current URI (if any).
* If there is an identity in use at the URI, after confirmation it is
removed.
* Otherwise the user is prompted to select an existing identity or
create a new one, as if 60 had been received.
>> Certificates
* To minimise information leakage to the server, all certificates, for
both anonymous and named identities, are created the same way apart from
the Common Name.
* The expiration date is set to 2 years in the future. I'm not sure if
this is the best compromise.
* The "valid from" date is set to 1 year in the past. Why not set it to
the current time? It's a known problem that users "in the wild" often
don't have correctly set clocks -- they don't set the right time zone,
then set the clock to make the time "look right". Since gemini servers
are meant to be widely deployed, we shouldn't expect either client or
server to have the right time. So we should backdate certificates by at
least a couple of days, and then a year seems a nice round safe choice.
* The serial number is set to 0, no extensions are set, and the
distinguished name consists only of the Common Name.
* The key is 2048 bit RSA with public exponent e=65537, and with hash
algorithm SHA256. I would have liked to use Ed25519, which is more
efficient in size and processing, but not all servers accept it.
>>> Fingerprinting
Currently, these choices identify diohsc uniquely. Hopefully a future
version of the spec will suggest defaults to prevent such
fingerprinting, and I think these would be reasonable choices. But it
could be worth considering mandating Ed25519, even if this means only
TLS1.3 servers can use client certificates. This can be considered an
"advanced" feature for a server, so it isn't so much of a problem if
some servers aren't capable of it.
>> Libraries
I used Vincent Hanquez's excellent pure-haskell cryptography libraries
to create and use client certificates. Neither openssl nor gnu-tls are
involved at all.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200607/b0e9
61b6/attachment.sig>
2. solderpunk (solderpunk (a) SDF.ORG)
* 📅 Sent: 2020-06-07 20:37
* 📧 Message 2 of 17
On Sun, Jun 07, 2020 at 08:54:39PM +0200, mbays at sdf.org wrote:
`! I just finished adding client certificate support to my line-based textual`!
`! gemini client diohsc. This involved making some non-trivial choices, and I`!
`! didn't copy av98 in all cases, so I hope discussing the decisions I made and`!
`! the reasoning behind them could be of use to other client developers and in`!
`! refining the spec.`!
Good! The way stuff is done in AV-98 current is *not* supposed to be
normative. It's supposed to give us the ability to experiment with
different client certificate work flows so we can see what works and
does not.
`! ## User interface`!
`! * The technical terminology "client certificate", which describes an`!
`! implementation detail rather than the underlying concept, is mostly hidden`!
`! from the user. Instead, the client talks about "identities". An identity is`!
`! just a client certificate along with an optional name.`!
`! * In diohsc, there are two kinds of identity -- temporary anonymous`!
`! identities and long-term named identities. The latter are saved to disc, the`!
`! former are held only in memory.`!
`! * There is no way to name and save an anonymous identity. Allowing it would`!
`! complicate the UI and the conceptual distinction between the two kinds of`!
`! identity.`!
This all sounds pretty sensible.
`! ### Creating identities`!
`! * When 61 is received, the user is asked if they want to create an anonymous`!
`! identity.`!
`! * On any other 6* error code, the user may select an existing named identity`!
`! or create a new named or anonymous identity, and then retry the request.`!
`! * When creating a named identity, the user is prompted to set a Common Name`!
`! (which can be empty). This is the only choice required of the user. It would`!
`! make for a neater UI to automatically set the Common Name to be the name of`!
`! the identity, and in some ways it would make sense. But the user may well`!
`! want to use the same Common Name (e.g. "anon" or "") on multiple servers`!
`! without a common identity.`!
For what it's worth, I am thinking pretty heavily about deprecating the
current status code 61 (and 21). They totally violate the idea that all
status codes should degrade gracefully in super simple clients which
ignore the second digit. If 61 is interpreted as 60, there is no
guarantee that the resulting certificate will be transient as intended,
and if 21 is interpreted as 20 the active certificate may not be deleted
as soon as the server is done with it.
I am increasingly thinking that having a single code for on-demand
certificates and encouraging clients to implement the
transient/persistent distinction themselves, like you are doing with any
other 6* code.
`! ### Using identities`!
`! * An identity can be set to be used on a given server at and below a given`!
`! URI path. So you can have one identity in use for`!
`! gemini://foo.bar/~quux/..., and another for gemini://foo.bar/~xuuq/...`!
`! * Whenever an URI is shown to the user, it is annotated with the identity,`!
`! if any, which would be used if it were requested; e.g.`!
`! "gemini://foo.bar/~xuuq/hello.gmi[clarkKent]". This includes relative URIs`!
`! in links. So the user knows when they're going to use what identity.`!
`! * Colouring is used to visually separate the annotation from the URI (but`!
`! '[' and ']' are reserved characters in URIs, so this isn't actually`!
`! necessary).`!
`! * Anonymous identities are denoted as "[]".`!
`! * If the user requests an URI which would use an identity which hasn't been`!
`! used in 30m, they are asked to confirm whether they want to still use it. If`!
`! they don't want to, the identity is disabled for this path.`!
This also all sounds really good! How does a certificate come to be
restricted to a given URL path and subpaths? Is it just up to the user
to take an educated guess at the required scope for a cert and manually
specify the path? I have been thinking that perhaps the <META> line for
status coedes 6x could be used for the server to specify precisely this
information.
`! ### Controlling identities`!
`! * There is a single new command added to deal with identities: "identify`!
`! [URI]". If URI is missing, it defaults to the current URI (if any).`!
`! * If there is an identity in use at the URI, after confirmation it is`!
`! removed.`!
`! * Otherwise the user is prompted to select an existing identity or create a`!
`! new one, as if 60 had been received.`!
Aah, so this is how certs get associated with a path.
`! ## Certificates`!
`! * To minimise information leakage to the server, all certificates, for both`!
`! anonymous and named identities, are created the same way apart from the`!
`! Common Name.`!
`! * The expiration date is set to 2 years in the future. I'm not sure if this`!
`! is the best compromise.`!
`! * The "valid from" date is set to 1 year in the past. Why not set it to the`!
`! current time? It's a known problem that users "in the wild" often don't have`!
`! correctly set clocks -- they don't set the right time zone, then set the`!
`! clock to make the time "look right". Since gemini servers are meant to be`!
`! widely deployed, we shouldn't expect either client or server to have the`!
`! right time. So we should backdate certificates by at least a couple of days,`!
`! and then a year seems a nice round safe choice.`!
`! * The serial number is set to 0, no extensions are set, and the`!
`! distinguished name consists only of the Common Name.`!
`! * The key is 2048 bit RSA with public exponent e=65537, and with hash`!
`! algorithm SHA256. I would have liked to use Ed25519, which is more efficient`!
`! in size and processing, but not all servers accept it.`!
I have also been wondering about putting something in the best practices
about certificate key types and sizes (based on discussions with 80h
about performance on their ESP8266 implementation). And about
ciphersuites generally, with a view toward minimising TLS overhead and
improving performance on low-power machines like Raspbery Pis.
`! ### Fingerprinting`!
`! Currently, these choices identify diohsc uniquely. Hopefully a future`!
`! version of the spec will suggest defaults to prevent such fingerprinting,`!
`! and I think these would be reasonable choices. But it could be worth`!
`! considering mandating Ed25519, even if this means only TLS1.3 servers can`!
`! use client certificates. This can be considered an "advanced" feature for a`!
`! server, so it isn't so much of a problem if some servers aren't capable of`!
`! it.`!
This is definitely worth giving consideration and the spec *should*
eventually say stuff about this.
Cheers,
Solderpunk
3. mbays (a) sdf.org (mbays (a) sdf.org)
* 📅 Sent: 2020-06-07 22:44
* 📧 Message 3 of 17
* Sunday, 2020-06-07 at 20:37 +0000 - solderpunk <solderpunk at SDF.ORG>:
`!On Sun, Jun 07, 2020 at 08:54:39PM +0200, mbays at sdf.org wrote:`!
`!`!
`!> ### Using identities`!
`!> * An identity can be set to be used on a given server at and below a given`!
`!> URI path. So you can have one identity in use for`!
`!> gemini://foo.bar/~quux/..., and another for gemini://foo.bar/~xuuq/...`!
`!`!
`!How does a certificate come to be restricted to a given URL path and `!
`!subpaths?`!
If an identity starts being used as the result of a 6* response to
a request, then the identity is subsequently used for all requests to
that path and anything below. Same if the "identify" command is used on
an URI.
This doesn't work entirely smoothly with astrobotony -- you might start
using our certificate at gemini://astrobotany.mozz.us/plant/, so it then
also takes effect for gemini://astrobotany.mozz.us/plant/water and so
on, but if you try e.g. gemini://astrobotany.mozz.us/settings you have
to select the identity again. You can manually "identify
gemini://astrobotany.mozz.us", but that isn't so smooth. Probably marks
should optionally have an identity associated -- that would help quite
a bit, but needs some forethought from the user.
If this method of restricting an identity to subpaths of the path it's
first requested at became normal, maybe servers would tend to arrange
everything which requires a certificate below a single "gate" root.
`!I have been thinking that perhaps the <META> line for status coedes 6x `!
`!could be used for the server to specify precisely this information.`!
That could work.
Cheers,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200608/a05b
2f1c/attachment-0001.sig>
4. Michael Lazar (lazar.michael22 (a) gmail.com)
* 📅 Sent: 2020-06-08 02:00
* 📧 Message 4 of 17
On Sun, Jun 7, 2020 at 7:14 PM <mbays at sdf.org> wrote:
`!`!
`! This doesn't work entirely smoothly with astrobotony -- you might start`!
`! using our certificate at gemini://astrobotany.mozz.us/plant/, so it then`!
`! also takes effect for gemini://astrobotany.mozz.us/plant/water and so`!
`! on, but if you try e.g. gemini://astrobotany.mozz.us/settings you have`!
`! to select the identity again. You can manually "identify`!
`! gemini://astrobotany.mozz.us", but that isn't so smooth. Probably marks`!
`! should optionally have an identity associated -- that would help quite`!
`! a bit, but needs some forethought from the user.`!
For what it's worth, I have been thinking about reorganizing the URL
structure for astrobotany so that all of the authenticated endpoints
live behind a single path. I am also planning on adding more
unauthenticated content to the server, so I want to establish a
clear separation between the sections that require a client certificate
and the sections that do not.
- gemini://astrobotany.mozz.us/
- gemini://astrobotany.mozz.us/about
- gemini://astrobotany.mozz.us/app (requires client certificate)
- gemini://astrobotany.mozz.us/app/plant
- gemini://astrobotany.mozz.us/app/directory
- ...
There are several other advantages to having a well designed path
hierarchy. It's something that I often don't spend enough time
thinking about up front and then I regret not doing it right later.
- Michael (mozz)
5. solderpunk (solderpunk (a) SDF.ORG)
* 📅 Sent: 2020-06-08 17:24
* 📧 Message 5 of 17
On Sun, Jun 07, 2020 at 10:00:02PM -0400, Michael Lazar wrote:
`! For what it's worth, I have been thinking about reorganizing the URL`!
`! structure for astrobotany so that all of the authenticated endpoints`!
`! live behind a single path. I am also planning on adding more`!
`! unauthenticated content to the server, so I want to establish a`!
`! clear separation between the sections that require a client certificate`!
`! and the sections that do not.`!
`! `!
`! - gemini://astrobotany.mozz.us/`!
`! - gemini://astrobotany.mozz.us/about`!
`! - gemini://astrobotany.mozz.us/app (requires client certificate)`!
`! - gemini://astrobotany.mozz.us/app/plant`!
`! - gemini://astrobotany.mozz.us/app/directory`!
`! - ...`!
`! `!
`! There are several other advantages to having a well designed path`!
`! hierarchy. It's something that I often don't spend enough time`!
`! thinking about up front and then I regret not doing it right later.`!
This seems wise to me. It's already pretty clear that associating
client certificates with domains, as currently specced (for transient
certs, at least) and as implemented in AV-98, is not the best idea. It
will inevitably cause confusion/frustration/difficulty in environments
where multiple users share a domain (like pubnixes). Associating them
with paths seems the obvious solution.
As the current leading implementer of client cert consumning apps, I'm
curious how you feel about the idea of using the <META> for 6x statuses
to convey an intended "path scope" for certs?
Cheers,
Solderpunk
6. Michael Lazar (lazar.michael22 (a) gmail.com)
* 📅 Sent: 2020-06-09 04:01
* 📧 Message 6 of 17
On Mon, Jun 8, 2020 at 1:25 PM solderpunk <solderpunk at sdf.org> wrote:
`!`!
`! On Sun, Jun 07, 2020 at 10:00:02PM -0400, Michael Lazar wrote:`!
`!`!
`! > There are several other advantages to having a well designed path`!
`! > hierarchy. It's something that I often don't spend enough time`!
`! > thinking about up front and then I regret not doing it right later.`!
`!`!
`! This seems wise to me. It's already pretty clear that associating`!
`! client certificates with domains, as currently specced (for transient`!
`! certs, at least) and as implemented in AV-98, is not the best idea. It`!
`! will inevitably cause confusion/frustration/difficulty in environments`!
`! where multiple users share a domain (like pubnixes). Associating them`!
`! with paths seems the obvious solution.`!
`!`!
`! As the current leading implementer of client cert consumning apps, I'm`!
`! curious how you feel about the idea of using the <META> for 6x statuses`!
`! to convey an intended "path scope" for certs?`!
`!`!
`! Cheers,`!
`! Solderpunk`!
I think hijacking the <META> is unnecessary for my application. I can accomplish
the same thing by sending a "30 TEMPORARY REDIRECT" to all unauthenticated
requests, and then hitting them with a 61 after they have been redirected to
the path scope. I concede that this wouldn't be *exactly* the same because the
client won't end up at the page that they originally requested. But it's
workable enough for me. And I like having the meta available for human readable
error messages.
Any complexity that we can remove from the spec surrounding client certificates
is a strong positive. I'm in favor of deprecating the 61 and 21 status codes.
Drop "64 FUTURE CERTIFICATE REJECTED" and "65 EXPIRED CERTIFICATE REJECTED"
while you're at it, they can be subsumed by "63 CERTIFICATE NOT ACCEPTED".
Heck, drop client certificates from the gemini specification all together.
Judging by the lack of client support so far, it's becoming clear that either:
1. They're a pain to implement compared to the rest of the specification
2. There's not much interest in actually using them
I get the vision behind the transient client sessions and fingerprinting stuff,
and it really is a nice idea. But it's also very prescriptive and unproven.
It sticks out when compared to the rest of the spec, which mostly borrows from
tried-and-true patterns already seen in gopher/WWW.
Best,
Michael
7. Sean Conner (sean (a) conman.org)
* 📅 Sent: 2020-06-09 04:40
* 📧 Message 7 of 17
It was thus said that the Great Michael Lazar once stated:
`! `!
`! Heck, drop client certificates from the gemini specification all together.`!
`! Judging by the lack of client support so far, it's becoming clear that either:`!
`! `!
`! 1. They're a pain to implement compared to the rest of the specification`!
`! 2. There's not much interest in actually using them`!
I personally would like to keep them, if only to protect sections of a
Gemini site from general consumption. The "transient client certificate"
idea is certainly problematic and I wouldn't mind if that concept went away
though.
-spc
8. solderpunk (solderpunk (a) SDF.ORG)
* 📅 Sent: 2020-06-09 07:42
* 📧 Message 8 of 17
On Tue, Jun 09, 2020 at 12:40:07AM -0400, Sean Conner wrote:
`! It was thus said that the Great Michael Lazar once stated:`!
`! > `!
`! > Heck, drop client certificates from the gemini specification all together.`!
`! > Judging by the lack of client support so far, it's becoming clear that either:`!
`! > `!
`! > 1. They're a pain to implement compared to the rest of the specification`!
`! > 2. There's not much interest in actually using them`!
`! `!
`! I personally would like to keep them, if only to protect sections of a`!
`! Gemini site from general consumption. The "transient client certificate"`!
`! idea is certainly problematic and I wouldn't mind if that concept went away`!
`! though.`!
I think it's probably a little too early in the game to interpet the
lack of client support as a lack of interest in using them. Many people
might be holding off on implementing them in the expectation that the
spec will change/simplify - which it surely will: I'm pretty much sold
on deprecating the transient client certificate status codes. There's
also an obvious chicken-and-egg problem here, where client authors have
no incentive to add support until servers require it to access
compelling content.
I too would like to keep *some* client cert support, though. I really
like the idea of being able to self-host little productivity apps for
myself which I can simply and reliably secure in an ssh-like fashion
(add my self-signed cert fingerprint to the equivalent of an
authorized_keys file). And, yes, okay, that doesn't strictly require 6x
status codes, the server could just immeditely cut the connection if it
didn't get a cert it liked. But it would be nice to be able to
gracefully use those apps from within an everyday client.
Mk's concern that "it'd be good not to hardwire SSL too strongly into
Gemini, in case the tooling around an alternative improves sufficiently
in the future and we'd like to swap" is a valid one, though, and one I
have (very occasionally) worried about. If nothing else this is a good
argument to keep our use of client certificates simple and perhaps not
to make use in apps of anything beyond the cert fingerprint (i.e. don't
rely heavily on the notion of Distinguished Names for Subject and
Issuer)...
Cheers,
Solderpunk
9. solderpunk (solderpunk (a) SDF.ORG)
* 📅 Sent: 2020-06-09 18:39
* 📧 Message 9 of 17
On Tue, Jun 09, 2020 at 12:01:28AM -0400, Michael Lazar wrote:
`! Any complexity that we can remove from the spec surrounding client certificates`!
`! is a strong positive. I'm in favor of deprecating the 61 and 21 status codes.`!
I was thinking of dropping 21 and "softening" 61 to mean something like
"you need a certificate to access this resource, and the server is
signalling that it's okay to use something temporary/disposable" - i.e.
to make it clear this is not an Astrobotany-style application where
losing your key/cert pair means forever losing access to your account.
Clients can handle this however they want - some clients will implement
good support for transient certs which never hit the disk, and will brag
about that, and users who really care will use them.
In general, I was thinking of just having a bunch of 6x codes which all
mean "you need a cert to get in here" but with different hints as to
what is expected - something you can generate yourself on the spot and
dispose of when you like, something you can generate yourself on the spot
and should take care to keep hold of (astrobotany style), or something
pre-approved by the admin (which might mean a CSR process, or just a
fingerprint whitelisting). No prescribed behaviour for any of them,
clients can give users as many or as few options for dealing with them as
the authors see fit, but at least this way they can convey enough
information to the user for them to make an informed choice.
`! Drop "64 FUTURE CERTIFICATE REJECTED" and "65 EXPIRED CERTIFICATE REJECTED"`!
`! while you're at it, they can be subsumed by "63 CERTIFICATE NOT ACCEPTED".`!
I expect Sean to object to this...
`! Judging by the lack of client support so far, it's becoming clear that either:`!
`! `!
`! 1. They're a pain to implement compared to the rest of the specification`!
This is true. I may amend the spec the explicitly call them an advanced
and optional feature. People should not feel ashamed of writing a
client that just opts out of the whole thing. To some extent the
existence of good clients which do this will act as a defence against
people putting stuff behind certificates without very good reason.
`! It sticks out when compared to the rest of the spec, which mostly borrows from`!
`! tried-and-true patterns already seen in gopher/WWW.`!
I like to think of at least the pre-approved cert workflow as
tried-and-true from ssh.
Cheers,
Solderpunk
10. Peter Vernigorov (pitr.vern (a) gmail.com)
* 📅 Sent: 2020-06-09 20:23
* 📧 Message 10 of 17
My two cents: I don?t understand why server gets to decide if user?s
certificate is transient or not. I as a user should make that decision. If
they want to lose access to their Astro plant, that?s their decision. In my
opinion there should just be one 6X status code, to request that user
retries with a certificate. If user didn?t use one, meta field should
explain why it is needed. If user used one - meta should explain why it was
declined (expiry, invalid, etc)
Using this logic, I would say status code 21 is similarly unnecessary. User
should be able to decide if they want to stop using client certificate.
AV-98 for instance allows user to do that (so does my iOS client). It seems
to me that status 21 tries to implement a logout functionality from the
web, where users have a jarfull of cookies and might not be able to delete
the right one. In Gemini on the other hand, it can be a simple toggle
switch.
On Tue, Jun 9, 2020 at 20:39 solderpunk <solderpunk at sdf.org> wrote:
`! On Tue, Jun 09, 2020 at 12:01:28AM -0400, Michael Lazar wrote:`!
`!`!
`! > Any complexity that we can remove from the spec surrounding client`!
`! certificates`!
`! > is a strong positive. I'm in favor of deprecating the 61 and 21 status`!
`! codes.`!
`!`!
`! I was thinking of dropping 21 and "softening" 61 to mean something like`!
`! "you need a certificate to access this resource, and the server is`!
`! signalling that it's okay to use something temporary/disposable" - i.e.`!
`! to make it clear this is not an Astrobotany-style application where`!
`! losing your key/cert pair means forever losing access to your account.`!
`! Clients can handle this however they want - some clients will implement`!
`! good support for transient certs which never hit the disk, and will brag`!
`! about that, and users who really care will use them.`!
`!`!
`! In general, I was thinking of just having a bunch of 6x codes which all`!
`! mean "you need a cert to get in here" but with different hints as to`!
`! what is expected - something you can generate yourself on the spot and`!
`! dispose of when you like, something you can generate yourself on the spot`!
`! and should take care to keep hold of (astrobotany style), or something`!
`! pre-approved by the admin (which might mean a CSR process, or just a`!
`! fingerprint whitelisting). No prescribed behaviour for any of them,`!
`! clients can give users as many or as few options for dealing with them as`!
`! the authors see fit, but at least this way they can convey enough`!
`! information to the user for them to make an informed choice.`!
`!`!
`! > Drop "64 FUTURE CERTIFICATE REJECTED" and "65 EXPIRED CERTIFICATE`!
`! REJECTED"`!
`! > while you're at it, they can be subsumed by "63 CERTIFICATE NOT`!
`! ACCEPTED".`!
`!`!
`! I expect Sean to object to this...`!
`!`!
`! > Judging by the lack of client support so far, it's becoming clear that`!
`! either:`!
`! >`!
`! > 1. They're a pain to implement compared to the rest of the specification`!
`!`!
`! This is true. I may amend the spec the explicitly call them an advanced`!
`! and optional feature. People should not feel ashamed of writing a`!
`! client that just opts out of the whole thing. To some extent the`!
`! existence of good clients which do this will act as a defence against`!
`! people putting stuff behind certificates without very good reason.`!
`!`!
`! > It sticks out when compared to the rest of the spec, which mostly`!
`! borrows from`!
`! > tried-and-true patterns already seen in gopher/WWW.`!
`!`!
`! I like to think of at least the pre-approved cert workflow as`!
`! tried-and-true from ssh.`!
`!`!
`! Cheers,`!
`! Solderpunk`!
`!`!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200609/6c95
230c/attachment-0001.htm>
11. solderpunk (solderpunk (a) SDF.ORG)
* 📅 Sent: 2020-06-09 20:45
* 📧 Message 11 of 17
On Tue, Jun 09, 2020 at 10:23:55PM +0200, Peter Vernigorov wrote:
`! My two cents: I don?t understand why server gets to decide if user?s`!
`! certificate is transient or not. I as a user should make that decision.`!
Definitely agree. I didn't mean for any of this to imply the server is
"in charge". The whole reason client certs are so great as a cookie
alternative is that they put the power squarely in the user's hands!
The problem, I think, is that users need to be able to *make* the
decision on an informed basis. If all I know is "the server needs a
cert", I will probably play it cautious and generate a transient one.
But if it turns out what the server wanted it for was to permanently tie
that cert's fingerprint to my ID, and I decide I quite like the service,
that's kind of a pain. Unless the server implements a potentially
fiddly re-association feature.
Of course, servers could explain what the cert should be used for (and
should!) in the <META> (unless we repurpose that for a path, which I
still think is worth thinking about), but some users may not understand
the implications. So I thought it would be nice for the server to be
able to provide a "hint" to inform the decision. Of *course* the user
should always be able to make up their own mind.
I guess this problem goes away in a client design where all certs are
generated as transient by default but users can then opt to mark a
particular cert as persistent? Hmm...
Cheers,
Solderpunk
12. Sean Conner (sean (a) conman.org)
* 📅 Sent: 2020-06-09 20:59
* 📧 Message 12 of 17
It was thus said that the Great solderpunk once stated:
`! On Tue, Jun 09, 2020 at 12:01:28AM -0400, Michael Lazar wrote:`!
`! `!
`! > Drop "64 FUTURE CERTIFICATE REJECTED" and "65 EXPIRED CERTIFICATE REJECTED"`!
`! > while you're at it, they can be subsumed by "63 CERTIFICATE NOT ACCEPTED".`!
`! `!
`! I expect Sean to object to this...`!
Not too terribly. I only added the bunch of codes to help with debugging
a rejection. I would accept the following:
60 client certificate required
61 client certificate invalid (or expired)
62 client certificate rejected
Just saying "bad certificate" isn't actionable enough for the user. Why
is it bad? Has it expired? Rejected? What? I NEED TO KNOW!
-spc
13. Tadeusz Sosnierz (tadeusz (a) sosnierz.com)
* 📅 Sent: 2020-06-09 21:06
* 📧 Message 13 of 17
2020-06-09 22:59 GMT+02:00 Sean Conner<sean at conman.org>:
`! Just saying "bad certificate" isn't actionable enough for the user. Why`!
`! is it bad? Has it expired? Rejected? What? I NEED TO KNOW!`!
Isn't that something that could go in the "meta" part of the response, or
the content itself?
The specificness of 6x codes is something I find quite puzzling,
especially considering how carefully select the other codes are.
Especially 64. When does that even come into play?
(Oh, and hi everyone; I'm new here, so excuse my perhaps silly questions :))
--
tadzik
14. Sean Conner (sean (a) conman.org)
* 📅 Sent: 2020-06-09 21:13
* 📧 Message 14 of 17
It was thus said that the Great Tadeusz Sosnierz once stated:
`! `!
`! 2020-06-09 22:59 GMT+02:00 Sean Conner<sean at conman.org>:`!
`! > Just saying "bad certificate" isn't actionable enough for the user. Why`!
`! > is it bad? Has it expired? Rejected? What? I NEED TO KNOW!`!
`! `!
`! Isn't that something that could go in the "meta" part of the response, or`!
`! the content itself?`!
It could, but what does it mean when I get back "n? ghlactar le deimhni?",
"di?lta?odh deimhni? sa todhcha?", or "di?lta?odh deimhni? caite"? Not
everyone speaks English and a numeric response is unambiguous.
`! The specificness of 6x codes is something I find quite puzzling,`!
`! especially considering how carefully select the other codes are.`!
`! `!
`! Especially 64. When does that even come into play?`!
Time skew between the client and server on a freshly minted certificate.
`! (Oh, and hi everyone; I'm new here, so excuse my perhaps silly questions :))`!
Hello, and no, your questions aren't silly.
-spc
15. Peter Vernigorov (pitr.vern (a) gmail.com)
* 📅 Sent: 2020-06-10 00:16
* 📧 Message 15 of 17
Wouldn?t the rest of that server?s content be also in the same language and
therefore not accessible to the user?
On Tue, Jun 9, 2020 at 23:13 Sean Conner <sean at conman.org> wrote:
`! It was thus said that the Great Tadeusz Sosnierz once stated:`!
`! >`!
`! > 2020-06-09 22:59 GMT+02:00 Sean Conner<sean at conman.org>:`!
`! > > Just saying "bad certificate" isn't actionable enough for the user. Why`!
`! > > is it bad? Has it expired? Rejected? What? I NEED TO KNOW!`!
`! >`!
`! > Isn't that something that could go in the "meta" part of the response, or`!
`! > the content itself?`!
`!`!
`! It could, but what does it mean when I get back "n? ghlactar le`!
`! deimhni?",`!
`! "di?lta?odh deimhni? sa todhcha?", or "di?lta?odh deimhni? caite"? Not`!
`! everyone speaks English and a numeric response is unambiguous.`!
`!`!
`! > The specificness of 6x codes is something I find quite puzzling,`!
`! > especially considering how carefully select the other codes are.`!
`! >`!
`! > Especially 64. When does that even come into play?`!
`!`!
`! Time skew between the client and server on a freshly minted`!
`! certificate.`!
`!`!
`! > (Oh, and hi everyone; I'm new here, so excuse my perhaps silly questions`!
`! :))`!
`!`!
`! Hello, and no, your questions aren't silly.`!
`!`!
`! -spc`!
`!`!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200610/cee6
f610/attachment.htm>
16. Sean Conner (sean (a) conman.org)
* 📅 Sent: 2020-06-10 01:29
* 📧 Message 16 of 17
It was thus said that the Great Peter Vernigorov once stated:
`! Wouldn?t the rest of that server?s content be also in the same language and`!
`! therefore not accessible to the user?`!
Why? Think of a server written with English error messages yet used to
serve up content in Thai. Most of the servers are written by English
speaking people, but that doesn't mean all users of said software speak
English---my example just turned that on its head. And it assumes that the
error messages can't be modified to a particular langauge.
-spc
17. solderpunk (solderpunk (a) SDF.ORG)
* 📅 Sent: 2020-06-10 21:16
* 📧 Message 17 of 17
On Tue, Jun 09, 2020 at 12:01:28AM -0400, Michael Lazar wrote:
`! I think hijacking the <META> is unnecessary for my application. I can accomplish`!
`! the same thing by sending a "30 TEMPORARY REDIRECT" to all unauthenticated`!
`! requests, and then hitting them with a 61 after they have been redirected to`!
`! the path scope. I concede that this wouldn't be *exactly* the same because the`!
`! client won't end up at the page that they originally requested. But it's`!
`! workable enough for me. And I like having the meta available for human readable`!
`! error messages.`!
Hmm...I think I like this. I mean, I'm never *super* excited when
redirects are involved, but this workflow would allow us to spec
that the default scope of a cert is all paths below the URI from
which the 6x status was received (which lets client certs be much
narrower in scope than cookies, which IMHO is a good selling point)
and still allow human-readable <META> for 6x statuses to provide
hints about expected certificate lifespan.
Cheers,
Solderpunk
---
you're on gemi.dev/gemini-mailing-list/000191.gmi